If you want to understand speed, live in the Midwest. It is in our blood. From the earliest age, Ohioans learn that going anywhere else takes a while. Eight hours to New York. Thirty-two hours to California. The Buckeye State is lovely, with its wide prairie lands and lush forests. However, families go elsewhere to vacation. Many fly south to Florida. Others head southeast, toward the Carolinas. My family did neither. We drove to Missouri. Our semi-annual, 10-hour road trip served as a curriculum for a future UX designer, including several lessons about distance, duration, and speed.
Mockup of a make-believe Mad Libs question
One person calls out to the group “I need a famous location… I need a name of a profession… I need a type of food.” He or she then fills in the omitted words.
Mockup of a make-believe Mad Libs answer
Ask. Think. Answer. Repeat. Before you notice, you arrive in Missouri.
For a game first published in 1958, Mad Libs is surprisingly similar to the input-output (IO) mechanisms of modern day software. Software requires specific inputs, such as a first name. Once you input this information, the system might output, “Hello, Bob.” With Mad Libs, your input are phrases, and the output is a story. With software, your input is data, and the output is an experience. Speed affects both the input and output.
Imagine the game of Mad Libs, but slow down the process of asking and answering each question by a few seconds, like the following:
“I need a famous location”
…
…
…
“Hmm… let me think about that one…”
…
…
…
…
…
…
“Okay, give me a second; I’m writing that down “
…
“I need a girl’s name”
…
…
…
…
…
“Hmm… let me think about that one…”
…
…
…
…
…
…
“Okay, give me a second; I’m writing that down…”
…
…
…
…
…
…
“I need a type of food…” and so on…
Even in this written example, you notice how the slowdown in speed can affect the game. The questions come less frequently. Answers are few and far between. The experience lumbers along, zapping the fun out of each subsequent round of game play.
Speed affects everything. When software is slow, simple tasks frustrate and complex tasks fail.
In Stoyan Stefanov’s book, Book of Speed , he notes that website users perceive page times to be 15% slower than their actual speed during use. Even more interesting, users perceive the same website to be 35% slower than the actual speed after using it. Our memories of speed are even slower than the actual speed.
We should consider both current and future perceptions of speed when designing experiences. Not only do we want new users, but we also want past users to return. Attracting users is a challenge. Retaining them is a triumph. Those users could have gone jogging, grabbed a bite to eat, played with their kids, walked their dog, done their laundry, watched TV, played a video game, read a newspaper, wrote an email, talked on the phone, got an oil change, shaved their legs, trimmed a ficus tree, danced in their kitchen, read a book about user experience, or really anything. But instead, they visited your website. Yet, after three seconds of waiting for your page to load, more than half of them will have abandoned it.1
Mobile users are even less compromising.2 Mobile websites frequently have only one chance to get it right or suffer the lasting consequences. A full third of mobile users report speed as their largest frustration, and half of those frustrated users will never return.
Mozilla, the makers of the browser Firefox, reduced its page load times by 2.2 seconds and they increased downloads of its browser by 60 million.3
Amazon.com famously noted that a decrease of 100 milliseconds increases their overall revenue by 1%.4 Consider that for a moment. Amazon net sales were $107 billion dollars in 2015. One percent of that is over 1 billion dollars. So, one-tenth of a second could buy three Boeing 777 jetliners.
A user’s perception of speed is the result of expectation minus duration. The shorter the expectation, the quicker an experience must perform. Patience becomes a vanishing commodity—not unlike the users themselves.
The Hick-Hyman Law
You witness the Hick-Hyman Law (or Hick’s Law) every day. You select a pair of socks, you peruse the aisle of a grocery store, you tap a link within a website menu. You might be surprised to learn that researchers have studied the speed of such interactions for the better part of a century.
The experimental psychologist, William Hick, published his groundbreaking research “On the Rate of Gain of Information5” in 1952. He measured the response times of study participants when confronted with multiple choices.
Participants were shown a series of lights. A lightbulb flashed, then a participant pressed a corresponding button. A moment later, another lightbulb flashed, then a participant pressed its corresponding button. Researchers would measure a participant’s response times from viewing a flash to selecting a button.
The study’s results showed correlations between the number of lights and response time. The more choices a person must consider, the longer a person takes.
Flashing lights and pressing buttons may not rival Nintendo’s The Legend of Zelda or Microsoft Excel, but the study can tell us a lot about human-computer interaction.
On the surface, Hick’s Law proves the old adage “less is more”: two choices are better than three; one alternative is better than two. However, that is an oversimplification. Having more choices leads to longer reaction times, but other factors also affect a person’s decisions. We remember. We practice. We reason.
Subsequent studies concluded that participants quicken their reaction times through practice.6 Your interaction with system controls—radio buttons, check boxes, list menus, and the like—also improves over time. As the saying goes, “How do you get to Carnegie Hall? Practice, practice, practice.”
Additionally, we must consider a user’s prior knowledge. A menu may contain a listing of 50 states, but a user already knows where she lives. Such thoughts are nearly instantaneous. A user also makes selections based on the alphabetization of a list (e.g., she looks for “N” because she wants to select “New York”).
Related studies have shown that people sometimes slow down their review of a shorter list and speed up their review of a longer list. Content plays a role. You would likely review a list of former lovers more attentively than a long list of auto parts. Unsurprisingly, longer lists generate more recall errors, while shorter lists generate fewer. (No offense to your love life intended.) A short list is easier to remember, but it is not always faster to review.
Hick’s Law offers us a practical insight: we need to balance the number of choices with the speed of making a choice. Choices should illuminate the user experience, not snuff it out. After all, user experience is more than a flashing bulb.
Key Takeaways
When an experience is slow, simple tasks frustrate and complex tasks fail.
Our memories of speed are slower than the actual speed.
A user’s perception of speed is the result of expectation minus duration.
The more choices a user must consider, the longer a user takes to consider.
Users quicken their reaction times through practice.
Users sometimes slow down their review of a shorter list and speed up their review of a longer list.
Questions to Ask Yourself
How does an experience perform using a low-bandwidth network, such as 3G?
When do users expect an experience to begin and complete?
What can I do to further optimize an experience?
How much practice have these users had?
How many choices am I asking the user to consider?